Timeboxing

Timeboxing is a planning technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget. Timeboxing is a core aspect of rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development.

Timeboxes are used as a form of risk management, especially for tasks that may easily extend past their deadlines. The end date (deadline) is one of the primary drivers in the planning and should not be changed as it is usually linked to a delivery date of the product. If the team exceeds the deadline, the team failed in proper planning and / or effective execution of the plan. This can be the result of: the wrong people on the wrong job (lack of communication between teams, lack of experience, lack of commitment / drive / motivation, lack of speed) or underestimation of the (complexity of the) requirements.

When the team exceeds the deadline, the following actions might be taken after conferring with the Client:

1. Dropping requirements of lower impact (the ones that will not be directly missed by the user)
2. Working overtime to compensate for the time lost
3. Moving the deadline

Triple constraint management

There are three main constraints to managing projects: time, cost, and scope (often extended to four including quality).

Without timeboxing, projects usually work to a fixed scope, such that when it is clear that some deliverables cannot be completed, either the deadline slips (to allow more time) or more people are involved (to do more in the same time). Usually both happen, delivery is late, costs go up, and often quality suffers (if only that requirements had changed by the time the project delivered).^{[citation needed]}

With timeboxing, the deadline is fixed, but the scope may be reduced. This focuses work on the most important deliverables. For this reason, timeboxing depends on the prioritisation (with the MoSCoW Method for example) of deliverables, to ensure that it is the project stakeholders who determine the important deliverables rather than software developers.

A lack of detailed specifications typically is the result of a lack of time, or the lack of knowledge of the desired end result (solution). In many types of projects, and especially in software engineering, analyzing and defining all requirements and specifications before the start of the realization phase is impossible. Timeboxing can be a favorable type of contracting for projects in which the deadline is the most critical aspect and when not all requirements are completely specified up front.^{[citation needed]}

The advantages of timeboxing over working with more traditional methods - in which there is a need to specify all details and features upfront - are that work can be started on the actual solution, or product, sooner, because less requirements and specifications gathering is necessary upfront. There is also a better structure for allowing for new insights that are developed during the project to be reflected in the end result.^{[citation needed]}

Personal timeboxing

Individuals can use timeboxing for personal tasks, as well. This technique utilizes a reduced scale of time (e.g., thirty minutes instead of a week) and deliverables (e.g., chores instead of a component of a business project). Personal timeboxing also works to curb perfectionist tendencies by setting a firm time and not overcommitting to a task.

This method can also be used to overcome procrastination.

See also

• Pomodoro Technique

External links

• Agile Requirements Change Management
• Designing To Schedule
• MSDN - How To Use Timeboxing for Getting Results